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(S) Personal date/time notary device. 



(57) A personal date/time notary device is 
embodied in a token device such as a "smart 
card" (1). The portable notary device includes 
an input/output (I/O) port (2), which is coupled 
to a single integrated circuit chip (3). The I/O 
port may be coupled to a conventional smart 
card reading device which in turn is coupled to 
a PC, lap-top computer or the like. A tamper 
resistant secret private key storage (6) is 
embodied on the chip. The private key storage 
is coupled to a processor (4) which, in turn, is 
coupled to a permanent memory (8) that stores 
the program executed by the processor. At least 
one clock (12) is embodied on the card. A 
second clock 14 and a random value generator 
10 are also preferably coupled to the processor. 
The device combines digital time notarization 
into a digital signature operation to ensure that 
a time stamp is always automatically present 
The user does not need to be involved in any 
additional decision making as to whether time 
stamping is necessary. 
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BACKGROUND AND SUMMARY OF THE 
INVENTION 

Since th advent of digital signatures, the pot n- 
tial exists for more transactions to be accomplished 
electronically. Using digital signatures, it is possible 
to undeniably determine that the party performing the 
signature operation is properly authorized to do so. 

Digital signatures having a "historic" value, such 
as those associated with an electronic contract are 
becoming increasingly common. In such an electronic 
contract, it may be important to be able to prove when 
a particular digital signature was performed (e.g., be- 
fore or after the time of a possible public key revoca- 
tion). With many electronic documents, such as con- 
tracts, journals, eta, signatures of historical signifi- 
cance become part of archived records. Without be- 
ing able to confirm exactly when such signature was 
performed, revocation of a public key as of a particu- 
lar point in time may cast doubt on any future verifi- 
cation of signatures which may have been performed 
months or years ago. 

Accordingly, it is useful to know with certainty the 
date and time of a digital signature, particularly in the 
context of electronically maintained diaries, inven- 
tor's scientific logs, journals, electronic bids, con- 
tracts or the like. It is also useful to convincingly dem- 
onstrate to a third party the signature time and sig- 
nature ownership. 

One way to solve this problem is to "notarize" all 
signatures having possible historic importance such 
as, for example, by using the applicant's time/date no- 
tary facility such as is described in U.S. Patents Nos. 
5,001,752 and 5,163,643, which patents are incorpo- 
rated herein by reference. These patents describe an 
effective manner for performing such notarization us- 
ing a secure device embodying a trusted clock to 
countersign important digital signatures by signing 
them in conjunction with the notarization time taken 
from the device's trusted time source. 

To effectively use known digital notaries requires 
that someone recognize in advance that the signature 
will have historic importance and remember to apply 
a time notarization to the digital signature. The user 
also must route the signed material (or some hash 
thereof) through the time notary device. Thus, the 
user must have access to the trusted time notary fa- 
cility some time soon after the creation of the digital 
signature. 

Practically speaking th digital notary device may 
n t be available at th time the digital signature is 
constructed. The signer may fail to rememb r to have 
his or her signature n tarized in atimelyfashi n.This 
is particularly likely to occur when digital signatures 
are made with portable devices such as a lap-top 
computer, where the user is often away from his or 
her normal place of business. With som material, it 
may not be clear at th time of signing, that a nota- 



rized time stamp is important 

The pres nt invention advantageously combines 
digital time notarization into a digital signature oper- 
ati n to ensure that a time stamp is always automat- 

5 icallypres nt Th user does not need to be involved 
in any additional decision making as to whether time 
stamping is necessary. By eliminating the need for a 
separate time stamp notarization device, the user 
saves time, money and effort 

10 The present invention is embodied in a token de- 
vice, e.g., such as a Smart Card, Smart Disk, or a 
MCIA device so that it is more readily available than 
a separate time stamp notarization device and easier 
to use with portable devices such as laptop comput- 
es ers. The method and apparatus described herein ad- 
vantageously allow an automatic trusted time stamp 
to be incorporated into user's digital signature opera- 
tion so that no additional user steps are necessary. 
The applicant's smart card/token type media can be 

20 used to simultaneously perform a time stamp notari- 
zation as part of a digital signature at a user's home 
in association with the user's personal computer (PC) 
or away from home in conjunction with a portable de- 
vice such as a lap-top computer. By simultaneously 

25 obtaining a time stamp notarization as part of the dig- 
ital signature, any verifier not only may prove that the 
signature was performed by the user, but also may 
prove when the signature took place. 

The present invention contemplates various al- 

30 ternative embodiments or modes of implementation 
via which the trusted time stamp is incorporated into, 
or associated with, the user's signature. Digital cer- 
tificates usually accompany digital signatures to at- 
test to the identity and the attributes of the entity as- 

35 sociated with a private/public key. In accordance with 
an embodiment of the present invention, the factory 
certifies the public key associated with the personal 
date/notary device of the present invention. The 
same key may also be certified as belonging to the 

40 owner/operator of the token device. Alternatively, the 
device may contain a second key for the user which 
is separately certified with the user's identity. Imple- 
mentations are also contemplated where the certifi- 
cates are maintained externally to the device (e.g., in 

45 storage associated with a computer driving the notary 
device) or internally so that they can be emitted, if de- 
sired, as part of the signing operation. 

The present invention advantageously permits 
every digital signature to be time stamped in a trusted 

so way so the us r no longer must decid wheth r the 
material is imp rtant nough to time stamp. Since ev- 
ery signature generated by a n tary device in accor- 
dance with th pres nt invention can be accurately 
placed in time, it become relatively simple t automat- 

55 ically determine the validity of a user, even if the 
user's smart card is lost or stol n or even if the author- 
ity f the user is eventually revoked. At any future 
time, it can readily be d termined when a digital sig- 
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nature with a trusted time stamp was performed. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Further features and advantages of the present 
invention will become apparent upon consideration of 
the following detailed description of the invention in 
conjunction with the following drawings of which: 
FIGURE 1 is a block diagram of an exemplary 
embodiment of the personal date/time notary de- 
vice of the present invention; 
FIGURE 2 is a flow diagram depicting the manner 
in which a personal date/time notary device is ini- 
tialized by the manufacturer; 
FIGURE 3 is a data flow/logic diagram showing 
how a notary device may be operated in accor- 
dance with first and second exemplary embodi- 
ments of the present invention; 
FIGURE 4 is a flow diagram showing how the per- 
sona) notary device may be operated in accor- 
dance with a further embodiment of the present 
invention; and 

FIGURE 5 is a flowchart showing how a proof set 
generated by the notary device of the present in- 
vention may be verified. 

DETAILED DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram of a personal 
date/time notary device in accordance with an exem- 
plary embodiment of the present invention. The de- 
vice is preferably embodied in a token device such as 
a "smart card" 1. Alternatively, the notary device 1 
may be embodied on a MC1A card which is thicker 
than a conventional smart card and typically includes 
at least several megabytes of storage. The media 1 
may alternatively be a "smart" diskette or virtually any 
kind of personal token device that can be carried or 
worn by a user. If embodied in an item worn, such a 
token device may include a security feature causing 
the device to be deactivated upon sensing removal 
from the user. Reactivation would require entry of a 
password. Such a token device may be embodied in 
an integrated circuit mounted in a wristwatch or a ring 
worn by a user or other jewelry or traditional personal 
items (cuff links, tie clasp, earrings, etc.). 

The portable notary device 1 includes an in- 
put/output (I/O) port 2 f which is coupled to an integrat- 
ed circuit, preferably, a single chip 3. I/O port 2 may 
b c upled to a conventional smart card reading de- 
vic (not shown) which in turn is coupled to a PC, lap- 
t p computer r the like. 

A tamper resistant secret private key storage 6 is 
embodied on chip 3. Attempts to penetrate the d vice 
1 may, for exampl , trigg r processor 4 to ov rwrite 
the secret key. The secret private key storage 6 may, 
for example, be a s cure RAM or a write-once mem- 
ory. The secret private key storage 6 stores at least 



the private key associated with the user who has cus- 
tody of ( r owns) the smart card 1 . 

In accordance with ne exemplary mbodiment 
f the present invention, th same user's private key 

5 may also be associated with the digital time notary 
function. Alternatively, a separate private key may be 
used for the notary function. 

The private key storage 6 is coupled to processor 
4 which, in turn, is coupled to a permanent memory 

10 8 that stores the program executed by processor 4. 
Processor 4 may be any one of a variety of commer- 
cially available microprocessors. Processor 4 may, 
for example, be a Motorola 6805. The particular proc- 
essor should be chosen depends on practical consid- 

15 erations familiar to those skilled in the art, such as 
cost and the processing power needed to implement 
the algorithm used to perform the digital signature op- 
eration. In the present invention, the RSA algorithm, 
which is described in Rivest et al U.S. Patent No. 

20 4,405,829 or the DSS (Digital Signature Standard) is 
preferred. It is, however, contemplated that algo- 
rithms other than RSA or DSS may be used in which 
case a processor with more or less computing power 
than the Motorola 6805 may be useful or sufficient 

25 At least one clock 12 is embodied on card 1 . In the 
presently preferred embodiment a second clock 14 
and a random value generator 10 are also coupled to 
processor 4. Clock 14 is utilized to enhance the ac- 
curacy of the time notary device 1 such that the actual 

30 clock value is taken as the average of the values gen- 
erated by clocks 12 and 14. The two clocks may be 
used to mutually check each other to insure neither 
becomes erratic. 

Random value generator 1 0 may, for example, be 

35 a well-known noise generating diode-based device. 
Any other random value generator may be used which 
takes advantage of the inherent randomness of an as- 
sociated physical device to maximize the random- 
ness of the value used by processor 4 in the digital 

40 signature process. 

Alternatively, random value generator 10 may be re- 
placed by instructions stored in permanent memory 
8 for generating a pseudo-random number via well- 
known software techniques. Each of the above- 

45 described components embodied on integrated cir- 
cuit chip 3 are powered by a suitable long life battery 
16, although in some embodiments, it may be useful 
to leave some components un powered except during 
operation. 

50 Although the personal date/tim notary device of 
the present invention is pref rably used to provide a 
time notarization for each signature, if desired, no 
such time n tarization necessarily need b provided. 
Additionally, processor 4 may be programmed to per- 

55 f rmed general purpose "smart" card related transao 
ti ns well known to those skilled in the art 

Turning next to Figure 2, the manner in which a 
manufacturer initializes a personal notary device is 
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described. Aft r fabricating the device 1 using con- 
ventional techniques (20), th program ROM 8 is 
loaded with the software which is to be executed by 
processor 4 (22). Th reaft r, initialization operations 
(23) begin. 5 

As indicated in block 24, a private/public key pair 
is created and stored. This operation takes place after 
the battery 16 is installed into the notary device 1. 
Preferably the device 2 generates its own private key 
so that it never exists outside the confines of the se- to 
cure notary device environment It is possible, how- 
ever, that the private key could be generated extern- 
ally and loaded into the device 1 but internal genera- 
tion is preferable for security reasons. Preferably, a 
private/public key pair is created using the RSA algo- 15 
rithm as described in the above-identified U.S. Patent 
No. 4,405,829. However, other algorithms may be 
used for creating a public/private key pair. 

A public key is output through I/O port 2 at some 
point in time although it need not be done during the 20 
initial key loading process. Preferably, the public key 
is not output until both notary device clocks 12 and 14 
are set If this precaution is taken, the device 1 must 
be completely initialized before it is possible to do any 
digital signatures. As part of the initialization process 25 
shown in block 26, the notary device 2 accepts the 
current date/time from a master clock having a high 
degree of accuracy. In accordance with the preferred 
embodiment of the present invention, clocks 12 and 
14 are both embodied in the device 1 to reduce the 30 
possibility of error or deliberate tampering attempts. 
It is contemplated that the manufacturer's master 
clock is set in accordance with Greenwich mean time, 
which is recognized throughout the world. The output 
of the manufacturer's master clock is coupled through 35 
I/O port 2 to processor 4 and then to clock 1 2 and 14. 
Using two clocks permits the processor to determine 
whether the clock 1 2 is functioning properly since the 
processor 4 monitors the difference in time between 
the output of clocks 12 and 14. 40 

As indicated at step 28, in the presently preferred 
embodiment after a period of time such as a day or 
week, the notary device 1 is resynchronized with the 
same master clock (or another accurate clock) and 
the "clock drift" unique to this hardware is deter- 45 
mined. This adjustment factor is then retained in the 
device's permanent memory. A calibrated clock read- 
ing may be determined by taking a first clock reading 
from the master clock, storing the first clock reading, 
taking a second clock reading from the master clock, so 
storing the sec nd clock reading, and counting the 
number of oscillations between the mast r clock 
readings. Then the actual oscillation frequ ncy may 
be calculated by using th oscillati n count divided by 
the diff rence between the second and first master 55 
cl ck readings to compute oscillations p r unit time, 
storing this calculated oscillation frequency and ad- 
justing the utput of the on-chip clock device in accor- 



dance with the calculated oscillati n frequency. The 
current time aft rcalibrati n may be computed by the 
steps of counting the number of oscillati ns since the 
first clock reading (a benchmark time), dividing this 
valu by the cal ibration value, adding the result to th 
said first clock reading. Assuming the uncertainty of 
the master clock reading is large compared with the 
oscillation period, this gives a clock accuracy of 
roughly no greater than twice the uncertainty of the 
master clock reading divided by the difference of the 
two master clock readings. Thus, an uncertainty of 
0.25 seconds in reading the master clock, where 
readings are separated by a week, would give a cali- 
bration-corrected accuracy of better than 1/million. In 
this manner, compensation may be made for any in- 
dividual deviations that exist as a result of manufac- 
turing variations. 

Since many digital clocks are known to vary 
slightly based on temperature, if dual clocks are 
used, it is possible to fabricate them in different ways, 
possibly from somewhat different materials, or differ- 
ent geometries, so that temperature variations will af- 
fect the clocks in different ways, each of which is un- 
derstood and known (e.g., different coefficients of 
drift). Although such drift is slight, it could be used as 
a second-order correction to detect and account for 
on-going clock drift due to temperature variations. 
Once both clocks were calibrated, for example, at a 
known controlled temperature, any mutual deviation, 
which although presumably would be slight, could be 
used to, in effect, gauge the temperature and provide 
for internal correction. This same approach could, of 
course, be used in any digital clock device in which 
clocks drifted in some understood way based on ex- 
ternal influences. 

As indicated in Figure 2 step 30, at the point the 
device initialization is deemed complete. Once load- 
ed, the program is designed such that as soon as the 
secret key is available, no further data or programs 
can be loaded unless all memory (including the secret 
key storage) is erased. The clock loading process is 
only allowed to occur once. 

It is contemplated that any loss of power, which 
would cause the clock to become invalid, would also 
be designed to render the device inoperative - so that 
the device will not produce spurious time readings. 

As indicated at step 32, the public key associated 
with the private key secretly stored in the notary de- 
vice is certified by the manufacturer as belonging to 
a trusted notary device. It may be desirable to f urth r 
test the d vice for correctness and durability before 
the factory certification is generated. Th manufac- 
turer gen rates a certif icat to indicate that th gen- 
rated public key is authorized f r us with this par- 
ticular user's notary device. This manufacturer's cer- 
tificate is thereafter associated with th card 1 . 

In accordance with the presently preferred em- 
bodiment, after the program xecuted by processor 4 
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is loaded into ROM 8, the program is executed to eith- 
er itself p rform steps 24-32 or assist in the perfor- 
mance of these steps by at least prompting connec- 
tion to a manufacturer's master clock (as is required, 
forexampl v in steps 26 and 28). 5 

The notary device of Figure 1 is designed to be 
implemented in accordance with various alternative 
mbodiments or modes of operation. A first mode of 
operation, uses a single private key. In this mode, 
there is a single resulting digital signature and a sin- 10 
gle certificate. The certificate establishes that a par- 
ticular user is operating with a private key in a trusted 
notary device. In this implementation, the certifier ex- 
plicitly indicates in the user's certificate that the 
user's private key is embodied in a secure device with 15 
a trusted clock. This might also be accomplished in- 
directly if the certifier was known (either explicitly or 
implicitly) to only certify users whose private key is 
operated within secured devices with trusted clocks. 

There are several ways in which the certification 20 
authority could ensure that the public key is matched 
with the private key in the secure time device. For ex- 
ample, a certificate issued by the device manufactur- 
er associating the public key with the trusted device 
may be utilized. In effect, the user's certifier vouches 25 
that the device contains the user's private key and 
also provides trusted time so that only the single cer- 
tificate is required. The advantage of this embodi- 
ment is that each public key may be accompanied by 
only one immediate certificate. In contrast, the other 30 
embodiments require two immediate certificates — 
one by the identifying certification authority binding 
the individual and one from the manufacturer demon- 
strating a secure clock device. 

If this first embodiment is utilized, there are some 35 
additional steps required by the certifier or the user, 
beyond those that may normally be taken to simply 
confirm that the public key is associated with the user. 
The additional steps confirm that the user's public key 
is indeed also associated with a trusted date/time no- 40 
tary device. 

In order to certify the user, initially a validation 
step is performed in which a validating certificate pro- 
vided by the manufacturing device indicates that the 
subject public key is properly associated with the no- 45 
tary device in question. That the user's public key is 
properly associated with the notary device may be 
confirmed by issuing a challenge with the expectation 
of getting a predetermined response to confirm that 
th subject key is properly associated with the notary so 
device. Then tary device may b operated in the cer- 
tifier's presence against rand m challenge data sup- 
plied by the certif i r so that the certifier is assured 
that the actual d vice produces an expected signa- 
ture (as verified with the anticipated public key). The 55 
certifier also checks that the date/time produced by 
the d vice is correct 

After verif icati n, the certifier constructs a cer- 



tif icat for the device's public key which indicates that 
th public k y reflects that the designated user oper- 
ates through a trusted n tary device. Such an indica- 
tion may be indicated explicitly in a certif icat or im- 
plicitly, e.g., by virtue that the certif i r is known only 
to certify user's who operate their private keys from 
trusted notary devices. 

The present invention may also be operated in 
accordance with a second embodiment which is sim- 
ilar to the first embodiment, except that two certifi- 
cates are generated for the same public key. One set 
of certifications comes from the "factory" confirming 
that the associated private key resides in the trusted 
notary device; the second from a certification author- 
ity confirming the association between the user and 
the public key. 

In the second embodiment, like the first, the de- 
vice contains a single private key associated with the 
user. This private key is certified by the device man- 
ufacturer as operating within a secure notary device 
environment The private key is also certified by an 
identifying authority confirming association between 
the notary device's private key and the individual who 
operates it 

Operation of the device results in the creation of 
a structure that includes the data to be signed (an 
electronic document) or some derivation of it (such as 
its hash); and the current time as determined by the 
device from its internal trusted clock. The private key 
is then used to digitally sign this aggregate structure 
(or some hash thereof). 

Subsequently, this signature can be verified by 
any entity having the public key corresponding to the 
secret private key stored within the device 1. In addi- 
tion, by keeping the two certificates associated with 
the key — the manufacturer's and the user's key — the 
verifying entity can determine that the signing key is 
associated with the particular user and also that the 
supplied time stamp is trustworthy. 

Steps which may be taken by a verif ier to confirm 
that the signature and a time stamp are valid may in- 
clude 1) insuring that the signature was correctly 
formed based on the signature value, the associated 
public key and the format expected for an embedded 
time stamp; 2) insuring that the certificate informa- 
tion of the user is valid and traces back to some root 
certificate which the verifier trusts (to thereby verify 
the identity of the user); and 3) insuring that the cer- 
tificate information provided by the manufacturer of 
th notary device indicates that the device incorpor- 
ates a trusted clock value into its signatures and that 
thev rifi r trusts th manufacturer to certify devices 
incorporating trusted time clocks. 

Figure 3 is a flow/block diagram which exempli- 
fies operation in accordance with the above- 
described first or s cond embodiments of the present 
invention. As shown in Figure 3, a digital value/docu- 
ment 40 to b signed is input to th card 1 via input 
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port 41 through a smart card interfac device (not 
shown). Valu 40 is coupled to processor 4, wh re the 
value is temporarily stored as indicated at step 42. 

Processor 4 th n extracts the current date and 
time from the on- board trusted clocks (12, 14) and 
stores this data as indicated at block 44. The digital 
value/document 40 to be signed (or some derivative 
thereof, such as its hash) is combined in an unambig- 
uous manner with the current date and time as shown 
in step 48. In step 50, the combined value is signed 
with the secret private key stored in storage device 6 
in accordance with known public key crypto method- 
ology. If desired, prior to performing the digital signa- 
ture operation processor device 4 may be program- 
med to first validate the user's personal identification 
password (PIN). 

In accordance with the first and second exem- 
plary embodiments, the notary device 1 uses a single 
private key stored in its private key storage 6. The re- 
sulting signed value is transmitted in step 54 to output 
port 56 which is part of I/O port 2 shown in Figure 1 . 
The digital value which is coupled to output port 56 is 
a digital signature which embodies the date/time in- 
dicia extracted from the trusted clocks 12 and 14. 

Through a smart card interface device (not 
shown), the output value from output port 56 is pre- 
ferably coupled to an external processor such as a 
personal computer or lap-top computer (58). As indi- 
cated in steps 62 and 64, any certificates which may 
be required are coupled to create a proof packet 60. 
The proof packet 60 established the identity of the 
public key with respect to the operator/owner of the 
personal signature notary device and establishes that 
the public key is incorporated into a notary device 
which constructs notarized personal signatures with 
a trusted date. 

These certificates, the output value from output 
port 56, and the original digital document, form the 
signature proof packet 60 generated by these exem- 
plary embodiments of the present invention. The cer- 
tificate-based data, the output of notary device 1 , and 
the digital document 40 may be combined in accor- 
dance with known public key-crypto standards for ap- 
pending ancillary material to a digital signature. The 
proof packet 60 may be stored in the user's computer 
system (58) and may be indexed in any of a variety 
of ways. For example, the signed value may represent 
the current day's entry in an inventor's journal and 
may be indexed as a file associated with the inven- 
tor's journal. If the n tary device 1 had sufficient stor- 
age capacity, it would be possible to use processor 4 
embodied within the card tog nerateth proof packet 
and store the packet in the associated memory. H w- 
ever, since the operati ns performed in generating 
the proof packet 60 do n t require a high lev I of se- 
curity, these perations may take place outside card 
1 with the us r*s computer. 

In accordance with third and fourth embodiments 



f the present inv ntion, the private key storage de- 
vice stores two private keys and generates two differ- 
nt signatures. The first private key is the private k y 
associated with the notary device, and the second pri- 

5 vate k y is associated with a particular user. The no- 
tary device private key is generated at the factory as 
described above (generally by the device itself) when 
the clock was initially calibrated certifying that the 
public key belongs to a secure clock device. The 

10 user's private key is also preferably generated by the 
device itself and is certified as belonging to the user 
who operates or owns the notary device. 

In this embodiment, operation consists of the de- 
vice producing two digital signatures, one with the 

15 user's private key and another with the device's own 
private key associated with the time stamp. Although 
the time and order of signature creation could be 
done several ways, it is preferred that a hash of the 
data being signed be combined with the current value 

20 of the secure clock and that this combined result be 
signed with the user's private key. Then this signature 
is signed with the device's private key. Alternatively 
other signing sequences may be utilized. For exam- 
ple, the subject material may be signed with the user's 

25 private key, then the result may be signed with the de- 
vice's notarization key. In this case, the final result 
would appear similar to the result of using a separate 
notary device to time stamp the user's signature. This 
approach would be compatible with more convention- 

30 al notarization techniques. Verification is done when 
operating in conjunction with this third embodiment 
by verifying both signatures (that of the user's public 
key and the notary's public key) and checking the re- 
spective certificates to ensure they are valid and 

35 trusted. 

The third mode of operation is similar to the first 
mode except that the initialization process differs. 
Turning back to figure 2, when operating in accor- 
dance with the third embodiment, an additional initial- 

40 ization step must be performed such that a second 
private signature key is generated and stored in the 
device's secret secure memory 6. Accordingly, the 
notary device contains two private signature keys 
stored in memory 6 such that the first key is generat- 
es ed while the notary device is being manufactured 
(ideally within the notary device itself) The second 
key may be generated at a later time and is associat- 
ed with the user. Actually, several different user keys 
could be generated and maintained with the device. 

so D pending n the application, it may be desirable to 
allow multiple keys to exist in parall I, or one at a time. 

In accordance with a fourth embodiment of the 
present inv nti n, the notary device preferably is em- 
bodied in a smart diskette constructed in accordance 

55 with German published patent application 
P4112023.9, which is incorp rated herein by refer- 
ence. The device perates as an interface between 
a wallet-siz d smart card and the diskett reader of 
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a PC. In this mbodiment, th notary device operates 
as a secure interface with which a smart card (or any 
oth r conventional digital signature device) interacts 
to achieve time notarizati n as part f a unified re- 
quest 5 

The notary device in this fourth embodiment does 
not contain the user's private key, but is only an inter- 
face (or "reader") which couples a smart card device 
to a computer (or other resource) which presents data 
to be signed. The device acts to combine a time no- 10 
tary device with a smart card device that performs the 
user's private key operations (where the smart card 
does not have a trusted clock). In this case, one can 
view the time notary device as being coupled to a 
smart card reader. 15 

In this embodiment, the device operates such 
that the data to be signed and time stamped is pre- 
sented to the notary device. The device interfaces 
with the user's smart card which operates the user's 
private card and returns a resulting signature. The re- 20 
suiting signature, which is returned to the device from 
the smart card (or some value derived from the sig- 
nature) is digitally signed by the device with its own 
private (notarization) key. The resulting combined sig- 
nature is then returned to the caller of the device. In 25 
this case, the result appears similar to that produced 
with the previously described embodiment above 
(where two signatures and two certificates are used). 
In accordance with this interface-based embodiment, 
a time notarization device also acts as a smart card 30 
reader which allows the effective "simultaneous" per- 
formance of time stamped user digital signatures. 
This embodiment, in effect, is a smart card reader 
which includes a time notarization device that produc- 
es a time notarized digital signature to a host PC or 35 
other hardware device. 

In accordance with the third embodiment, the op- 
erations depicted in Figure 3 must be modified such 
that the operations of block 42 actually produce a dig- 
ital signature by the user's private key of the material 40 
to be signed. The output value from box 42 then be- 
comes "value to be notarized" 42. 

Similarly, the initialization process of Figure 2 
must be augmented to show that a second public/pri- 
vate key pair is generated which exclusively repre- 45 
sents the user. However, this can be generated after 
the device leaves the factory — and could be gener- 
ated on user demand (unlike the notarization key 
which cannot be changed after it is certified by the 
manufacturer). There could, in fact, be several differ- so 
entus r private keys. 

In accordance with th fourth embodiment, the 
peration depicted in Figure 3 must be modified such 
that th operations of block 42 actually result in com- 
munications, through appropriate ports with the 55 
us r*s private k y token. In this mode, th processing 
shown in the box does not all occur within the person- 
al n tarization device (1) — however th utputofbox 



42 again (as in the third mod ) is a digital signature 
by the user's privat k y of the material to be sign d. 
The utput value from box 42 then becomes "valu to 
ben tarized"42. 

Th combin d resulting value is th n signed with 
the notarization private key (which has been generat- 
ed and certified at the factory). The combined result- 
ing value after being signed is output to output port 
56. In step 58, the necessary certificates for both 
public keys (the user's and the device's) are incorpo- 
rated into the final proof packet result 

In a further possible alternative embodiment a 
smart card trusted clock device is implemented to al- 
low a personal smart card-type device to incorporate 
trusted date/time notarization into a single resulting 
digital signature without requiring a trusted clock to 
reside in the smart card itself. This allows a more lim- 
ited (clock! ess device) to provide the same signature 
result (incorporating a trusted time stamp into a single 
personal digital signature as in the Figure 3 embodi- 
ment), but without a trusted clock on board the smart 
card-type device. In order to accomplish this end, the 
smart card is coupled with a date/time notary facility 
but using a different protocol than is used in the mode 
described above using a smart diskette as described 
in aforementioned German published patent docu- 
ment 

Although the trusted clock signature is only avai I- 
able when used with the trusted notary device, this 
may be acceptable for certain applications. The trust- 
ed clock digital notary facility could be incorporated 
into a smart card reader device so that interaction be- 
tween the smart card and the reader device could re- 
sult in a date/time, notarized digital signature similar 
to, or identical with, that produced by the alternative 
embodiments described above. 

Figure 4 depicts operation in accordance with 
this alternative embodiment and demonstrates how 
this embodiment may be incorporated into the meth- 
odology described in Figure 3. Step 48 of Figure 4 and 
step 48 of Figure 3 depict identical operations. Fur- 
ther operation then proceeds as previously described 
in conjunction with Figure 3. 

As shown in Figure 4, the smart card is given a 
value 410 to be digitally signed and date/time nota- 
rized. In accordance with block 420, the smart card 
produces a unique value and presents this value to 
the trusted date/time notary device. This is designed 
to prevent attack by an opponent attempting some- 
how to insinuate ("playback") a stale date/time valu 
into the communicati n. The unique valu may op- 
tionally be g n rated by an on-board random value 
generator or may be bas d n the value to be sign d. 

In accordance with step 430, the uniqu value is 
presented by the trusted date/time notary facility 
which is coupled to the smart card reader r is incor- 
p rated into it In accordance with step 440, th trust- 
ed date/time devic notarizes the offered unique val- 
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ue by signing in conjunction with the current time and 
returns it to the smart card. It is preferred that the 
trusted date/time d vice wilt also return the certifi- 
cat (or a certificate hierarchy). This certificate, typ- 
ically produced by the notary facility's manufacturer, 
serves to prove to the smart card that this time stamp 
is accurate and trustworthy. 

In accordance with block 450, on receipt of this 
signed value, the smart card then validates that the 
resulting notarization was performed on its unique 
value as provided in step 420 above. The smart card 
additionally validates that the certificates provided 
with the notarized value accurately describes the no- 
tarizing signature and that the certificates contain 
sufficient information to allow the smart card to deter- 
mine that the signature was, in fact, produced by a 
trusted notary device. Ultimately this information is 
validated based on root information loaded into the 
smart card when it was manufactured. Such root in- 
formation may include, for example, a root certificate 
by the notary manufacturer or its public key (or some 
hash thereof). Presuming that the certificates provid- 
ed by the notary device were signed by an authority 
recognized according to information stored within the 
smart card (such as the public keys in the notary fa- 
cility device or the pubic keys of the manufacturer of 
the notary device, or the hashes thereof), the smart 
card is assured that it has a current trustworthy clock 
value. As part of the verification, the smart card en- 
sures that the notarized value is derived from the 
unique value which is initially provided in step 420. 

In accordance with step 460, the smart card then 
uses the date/time provided by the notary device with 
effectively the same level of trust as if the trusted 
date/time notary device resided within itself. Thus, 
the trusted date/time can be incorporated into the sig- 
nature operation done with the user's public key. The 
smart card can be used with other applications (or 
with readers not coupled to a trusted date/time no- 
tary) except that signatures created would not be 
bound with a date/time notarization. Thereafter, sig- 
natures are created in accordance with the embodi- 
ment shown in Figure 3 and operation proceeds with 
step 48 shown therein. 

As a further alternative embodiment, the smart 
card type device may apply the user's private key 
first, then present that signature as data to a coupled 
smart card interface/time stamp notary device in 
which the user's signature and the time stamp notar- 
ization signature retain their separat identities. In 
this case, the coupling of th time/notary device and 
smart card read r (interface) provide for conv nient 
time notarization of the user's signature in a format 
consistent with ther uses of the date/time notary 
such as that outlined in applicant's U.S. Patent Nos. 
5,011,752 or 5,163,643. Alth ugh the preferred em- 
bodiments of the various modes always supply a time 
stamp, it is contemplated that an implem ntati nmay 



b created in which the time stamp may be condition- 
ally supplied. 

Figure 5 is flow diagram showing how an exem- 
plary proof set 500 may be verifi d. Thev rification 
5 peration requires no special security measures be 
undertaken. A recipient who receives material which 
has been signed, verifies the signature as described 
below. 

The recipient receives a proof set 500 including 

10 the value 10 of the object, i.e, a digital document to- 
gether with a sig nature produced by the notary device 
of the present invention which includes: the hash of 
the value of the signed object 508, the date/time 504 
as purportedly produced by a trusted notary device 

15 (which is proven in later verification steps), and the 
seal 506 produced by applying the private key which 
resides in the device operated by the user to the 
above information. Additionally, the proof set will in- 
clude certificates 62 and 64 which prove that the pub- 

20 lie key (counterpart to the private key stored in the de- 
vice) belongs to the user, and is operated in conjunc- 
tion with a trusted date/time notary. 

The entity which verifies the signature performs 
the following steps. The signature operation is veri- 

25 f ied to show that it correctly reflects the data which 
was signed and that it was correctly composed with 
the "purported" date/time. A hash of the value 1 0 (out- 
put 508), the date 504 and the seal 506 are input to 
verify the signature operation at 510. If the seal does 

30 correctly reflect the date 506 (as determined at 510), 
a determination is made in block 520 if an invalid sig- 
nature is detected. If so, an "invalid signature" mes- 
sage 525 is conveyed to the recipient If the seal 506 
does correctly reflect the data, then processing con- 

35 tinues at block 530. As indicated in block 530, the 
user's certificate is checked to confirm that the iden- 
tity of a signer was appropriately associated with the 
signer's public key. The invention contemplates addi- 
tionally verifying the authority possessed by the user 

40 if desired, in accordance with the applicant's en- 
hanced digital signature related methodology descri- 
bed in U.S. Patent No. 5,005,200. 

In accordance with step 540, confirmation is 
made using whatever certificates (or other informa- 

45 tion) are available that the public key is also associ- 
ated with and operated from the expected type of 
trusted date/notary device based on the contents of 
certificates 64 (which may be the same as the certif- 
icate for the user 62 in accordance with the first em- 

50 bodiment of the present inv ntion). It sh uld be ap- 
preciated that the precise v rification steps will vary 
depending upon which of the above-described m- 
bodiments is being utilized. 

In accordance with st p 550, a check is made to 

55 det rmine whether the notary key is valid and is cer- 
tified as belonging to a trusted date/time notary de- 
vice. If the notary key is n t valid, then a message is 
generated that the recipi nt cann t trust the notary 
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A device according to claim 1 , wherein said proc- 
essor device includes means for validating a 
user's personal identification passw rd (PIN) as 
a prerequisite to providing the digital signature. 

A device according to claim 1 , wherein said proc- 
essor device is prevented from performing digital 
signatures in response to attempted tampering. 

A device according to claim 1, wherein said se- 
cure storage device stores a plurality of private 
keys, said processor devices performs at least 
one digital signature operation using said plural- 
ity of private keys. 

A method for operating a user token device com- 
prising the steps of. 

a) receiving a digital value to be digitally sign- 
ed 

b) determining the current time from a trusted 
clock source; 

c) creating a digital data structure including 
the current time, and a value derived from in- 
formation to be signed; 

d) accessing at least one stored private key; 

e) digitally signing digital data said structure. 



and date. Alt rnativ ly. if a valid n tary key is detect- 4. 
d, then as indicated in block 570, confirmati n is 
made of th id ntity of the user and the notarized dat 
and time. 

In the above described embodim ntswh remul- 5 
tiple signatures are performed using the private no- 5. 
tarization key and the user's private key, verification 
is similar to what is described above in conjunction 
with Figure 5, except that multiple verifications per- 
formed by different public keys are used in verifying 10 6. 
the multiple signatures. 

When a Personal Identification Number (PIN) 
password is used in conjunction with the above- 
described embodiments, it could be presented to the 
token device in several ways including, for example, 15 
1) with the signature request; 2) encrypted under a 7. 
public key associated with the token device; 3) en- 
crypted under a secret key shared with the token de- 
vice; 4) used as encryption key, or to derive an en- 
cryption key, for signing or transmitting information to 20 
and/or from the token device. 

While the invention has been described in con- 
nection with what is presently considered to be the 
most practical and preferred embodiment, it is to be 
understood that the invention is not to be limited to the 25 
disclosed embodiment, but on the contrary, is intend- 
ed to cover various modifications and equivalent ar- 
rangements included within the spirit and scope of the 8. 
appended claims. 



Claims 



1. A token device fabricated on a portable medium 
carried by a user comprising: 

a secure storage device for storing at least 
one private key, wherein said at least one private 
key is used to perform digital signatures associ- 
ated with said user 

a clock for providing an indication of date 
and time; 

a communication port for receiving a value 
to be digitally signed and for emitting an output; 

a processor device coupled to said com- 
munication port and said clock for receiving said 
value to be digitally signed and said indication of 
date and time and for performing at least one dig- 
ital signature with said at least one private key for 
output to said communication port 

2. A device according to claim 1, further comprising 
a random number gen rator coupled t said proc- 
essor device. 

3. A device according to claim 1, further including 
an add it i nal clock coupled to said processor de- 
vice. 



A method according to claim 7, wherein said at 
least one said stored private key has an associ- 
ated public key certified as having its private key 
operating from within a secure time notary de- 
vice. 

9. A method according to claim 7, wherein said at 
35 least one said private key has an associated pub- 
lic key certified a being identified with a particu- 
lar individual. 

10. A method according to claim 7, wherein at least 
40 one certificate associated with said at least on 

stored private key is stored in the device. 

11. A method according to claim 7, wherein one of the 
certificates associated with said at least one stor- 

45 ed private key are stored outside of the device. 

12. A method according to claim 7, wherein said clock 
is permanently initialized at the time of manufac- 
ture. 

50 

13. A method according to claim 7, wh rein at least 
one of said private keys is created at tim of man- 
ufacture. 

55 14. A user token d vice based syst m comprising: 
secure st rage means for storing least on 
private key, wherein said at least one of said pri- 
vate keys is used to perf rm digital signatures as- 
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sociated with said us n 

communicati n means for receiving input 
digital signal and emitting digital output; 

processor means for rec iving said input 
digital signals and f r performing digital signa- 5 
tures with the said at least one private key; and 

means for interfacing with a trusted date- 
time notary device and for coupling via said com- 
munication means date and time related signals 
generated by said notary device to said proces- 10 
sor means. 

15. A system according to claim 14 wherein said se- 
cure storage means stores information used to 
identify a trusted date time notary device. 15 

16. A system according to claim 14 wherein said 
means for interfacing is coupled in use to at least 
one interface reader device for supplying input 

and output to the token device coupled to at least 20 
one trusted time notary device. 

17. A method for calibrating an on-chip clock device 
to compensate for individual deviation, including 

the steps of taking a first clock reading from a 25 
master clock; 

storing the first clock reading; 

taking a second clock reading from the 
master clock; 

storing the second clock reading; 30 

counting the number of oscillations be- 
tween the master clock readings; 

determining the actual oscillation frequen- 
cy using the difference between the second and 
first master clock readings to compute oscilla- 35 
tions per unit time; 

storing the calculated oscillation frequen- 
cy; and 

adjusting the output of the on-chip clock 
device in accordance with said calculated oscil- 40 
lation frequency. 

18. A method according to claim 17, wherein a cali- 
bration value computed for a clock of a time no- 
tary device is stored in memory in said device. 45 

19. A method according to 17, wherein the on-chip 
clock indicates current time, which after calibra- 
tion is computed with the steps of: 

counting th number of oscillati ns since so 
the first clock reading; 

dividing said number of oscillations by the 
calibration valu to obtain an adjustment value; 

adding said adjustment value to the said 
first clock reading. 55 
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